Global positioning devices, e.g., receivers, can receive signals from satellites in order to determine the position of the receiver. This can be useful to a user for a variety of reasons on both land and at sea. As technology has moved forward, a greater number of devices have the ability to receive and use satellite signals for determining position.
In Global Navigation Satellite System (GNSS) applications, the Ephemeris data for a satellite is used to calculate the satellites' position in orbit. The position of satellites is a fundamental requirement to generating a position and time solution in GNSS receivers. In all GNSS systems, the Ephemeris data is transmitted serially by the satellites. In situations where the Ephemeris data is not provided externally to the receiver system (such as via a data link) the receiver must collect the Ephemeris data before the corresponding measurements from the satellite can be used in the position and time solution.
The Ephemeris data collection is a serial process. For Global Positioning System (GPS) satellites, the Ephemeris (and Clock) information are transmitted in three subframes, where each subframe consists of ten, thirty bit, parity checked words. A further two subframes, containing GPS system data, complete five subframes, whereupon the Ephemeris and Clock data are repeated. The five subframe sequence takes 30 seconds to complete. Each subframe is six seconds in duration, and individual data bits have a period of 20 milliseconds.
An example of the 5 subframe Global Positioning System (GPS) data structure 100, as transmitted by GPS satellites, is shown in FIG. 1. A data structure 100 contains 5 subframes, each of the subframes has a duration of 6 seconds. Each subframe is composed of 10 words, while each word has a duration of 0.6 seconds, with a length of 30 bits. The Clock and Ephemeris data, required to compute the satellite's position, are contained in the data words (words 3-10) of subframes 1-3. Subframes 4 and 5 contain GPS system information, including status and approximate orbit parameters for all the other satellites in the constellation. Hence, in order for the satellite position to be calculated, the data words (3-10) of subframes 1, 2 and 3 is collected by the receiver, together with a reference time from the truncated Time-Of-Week in the word 1, which is also named as Telemetry word (TLM). Note that word 1 (TLM) and word 2 (Handover Word (HOW)) are common to all subframes and are shown in FIGS. 2 and 3, respectively.
As illustrated in FIG. 2, a TLM word (word 1) has a 30-bit sequence structure 200. The TLM word structure 200 starts with a preamble sequence. The preamble sequence is a string of 8 bits. In one or more embodiments, the preamble sequence is always 10001011 (represented in hexadecimal as 0x8B). The TLM word structure 200 further contains a TLM message sequence which has a length of 14 bits, and a parity sequence which has a length of 6 bits. The TLM word structure 200 also contains 2 bits for reserved services/data.
As illustrated in FIG. 3, a HOW word (word 2) has a 30-bit sequence structure 300. The HOW word structure 300 contains a truncated Time-Of-Week Count sequence which has a length of 17 bits, a Flag Bits sequence which has a length of 2 bits, a S/F ID sequence which has a length of 3 bits, a Parity preserving Bits sequence which has a length of 2 bits, and a parity sequence which has a length of 6 bits.
GPS receivers undergo a complicated procedure to collect and demodulate the satellite data. Because the pseudo random noise (PRN) code is of one millisecond duration, and the data bits are of twenty milliseconds duration, it is necessary to identify (without doubt), the millisecond containing the data bit edge. For strong signals this is relatively easy, but for weak signals, at the lower limit of when data demodulation is possible, this can take many bit edge transitions to achieve without any doubt of which millisecond contains the edge. This process to find the millisecond containing the bit edge can thus take many seconds to complete, especially when the data transmitted contains many consecutive ones or zeros, and hence very few data bit transitions. Because GPS satellites are at different locations in orbit, and thus at different distances from the receiver, the local receiver time millisecond containing the data bit transition can be different for each satellite.
Once the millisecond containing the data bit edge has been determined with 100% certainty (referred to as “achieving bit synchronization”), the receiver can then accumulate twenty millisecond complex time aligned data samples for each data bit and determine if the data bit is a “zero” or a “one”. The next process is to determine the start of the subframe. All subframes start with the eight bit preamble sequence 10001011 (hexadecimal 0x8B). Although this has often been referred to as the “unique word”, this is not the case and this 0x8B sequence of eight bits can occur frequently in the data stream. That is, it is also possible that other words in the subframe can also start with the sequence 0x8B. For example, there is a period in each week when the most significant bits of word 2 (the HOW word) are also 0x8B. Hence the start of the subframe cannot be determined by finding a sequence of 0x8B alone, even if all words pass parity.
Instead, to uniquely identify the start of a subframe with 100% certainty, the following checks are made: (1) Subframes must start with the 0x8B preamble sequence; (2) Subframes must contain 10 words, all of which pass the parity check; and (3) Two adjacent Subframes must be found and the difference between the truncated Time_of_Week (TOW) in the two TLM words must differ by six seconds. Only when all of the three checks just described pass, does the receiver know the start point of the data subframes, and the process of decoding the satellite data stream can commence.
So, using this method, the minimum time to collect the satellite Clock and Ephemeris data, contained in subframes 1-3, is 18 seconds. This is achieved only when bit synchronization and subframe synchronization are achieved just before the start of subframe 1 being received.
However, in practice, bit synchronization can be achieved at any point within the five subframe sequence. If bit synchronization is achieved mid-way through subframe 1 then the first subframe to be completely received is subframe 2. This is then followed by subframes 3, 4 and 5 before subframe 1 is repeated. Under these conditions it can take up to 36 seconds to completely receive the Clock and Ephemeris data contained in subframes 1-3. The time taken to collect Clock and Ephemeris data is thus between 18 and 36 seconds, plus the several seconds it takes to achieve bit synchronization, plus the “idle” time (illustrated as 460 in FIG. 4) waiting for the start of the next subframe to occur.
An example of this conventional method can be seen in FIG. 4 which shows an example of a conventional timeline 400 of satellite acquisition and Ephemeris collection with the completion of the Ephemeris collection 450 occurring after all of the subframes have been published. In time point 402, a satellite searching commences, e.g. when a GPS receiver is in a Cold Start condition. Once satellite acquisition is achieved in 404, a bit edge detection is performed. In time point 406, a bit edge is successfully detected, i.e. a bit synchronization is achieved. In one or more embodiments, a bit synchronization is achieved mid-way through subframe 1, which is the case illustrated in FIG. 4, then the subframe synchronization can be completed earliest after a start point of subframe 3 (which is illustrated as time point 408). I.e. the first complete received subframe is subframe 2, this is then followed by publishing subframe 3 at time point 410, publishing subframe 4 at time point 412, and publishing subframe 5 at time pint 414 successively. Then subframe 1 is repeated at time point 416, and consequently, a complete Ephemeris data which contains subframes 1 to 3 are collected. As the embodiment shown in FIG. 4, it may take up to 36 seconds to collect a complete Ephemeris data (illustrated as the hashes boxes).
Accordingly, it would be desirable to provide methods and systems which reduce the amount of time to collect Clock and Ephemeris data.